「走れ！プロジェクトマネージャー！」

プロジェクトの最初に、『スコープを定義する』ということが必要になります。何をするのか、をはっきりさせるということですね。
「なに？そんなこと、当たり前じゃないか！」と言われそうですが、その当たり前の手順を踏みましょう、ということです。
・・・で、世の中には、その手順を踏まない（自称）「プロジェクト」が多数存在します。もちろん、プロジェクトとして定義された時点で、「何をするか」がはっきりしているものもあります。
一方、何をやるのか、をはっきりさせるところからスタートするプロジェクトも少なくありません。はっきりしている「はず」だと思ったら、全然はっきりしていなかった、むしろ、当初の話しと違うことをやるべき、なんてこともあり得ます。というか、僕の周りでは、実際に存在します。

ところが、この『スコープを定義する』という作業をやらないPMがいたりします。いえいえ、ごめんなさい、PMと呼ぶべきではないかも知れません。でも、ここではPMとして登場します。
そのPMは、スコープを定義しません。何をやるべきか、を「勝手に考えて」進めていこうとします。もちろん、創造でやっているわけではないのです。「当初話されていたこと」、を基に進めようとします。
ところが、話しは既に変わっていたりするのです。何故か？
彼は、タスクベースでやるべきことを決めようとするからいけないわけです。タスクベース？なんだ？そりゃ？
そう思われる方がいらっしゃるかも知れません。
仕事は、「目標・目的」が存在し、その「目標・目的」を達成するためにやるべきこと（作業）を洗い出したら、タスクになるわけです。WBS（Work Breakdown Structure）を書いたときの、最下層に当たるWork package相当になるわけです。
一般的に失敗する可能性の高いプロジェクトは、WBSを描けずに、最下層のタスクを寄せ集めて、積み上げるから失敗するのです。網羅性に欠けるわけですね。
目標からBreakdownしたら、網羅しないはずがありません。
何かのシステムを作るとします。例えば、販売管理システム。エンドユーザ（発注者・依頼者）は、その販売管理システムを利用して、何を実現したいのか、を考える必要があります。
販売管理とは言っても、今まで何も出来ていなかったわけではないんでしょう、きっと。（会社を新設したのなら別ですが）
ただ、今回作る販売管理システムで、何を実現したいのか？
新しい商品販売が発生したのか、今までに取り扱っていなかった収益モデルが始まるのか、はたまた新たなサービス提供をするのか。そこを考えずに、ただただ「販売管理システム」を作っても、実際にやりたい「販売管理」は出来ないかも知れません。
では現実はどうか。
現実は、そんなことを考えずに進められている（自称）「プロジェクト」は少なくありません。
「お客さんが本棚を欲しい、と言ったので、本棚作って納品しました」と報告されているわけです。
そのお客さんが、本棚をどこに置きたいのか、（寝ながら読むので、ベッドの傍？音楽聞きながらゆったり読みたいので、リビングの真ん中？料理本を置くために、キッチンの片隅？）どのようなイメージか、（窓の傍だから、腰より低い？耐震含めて、天井まで届くタイプ？目の高さで、壁に打ち付け？）などなどを考える必要があります。
それを考えずに「顧客第一」なんて、チャンチャラおかしい。
それを考えてこそ、スコープを定義する、に行き着けるのだと思います。